<do> tag

<do> element

The <do> element associates a task with an element within the user interface (for example, a function key, graphically-rendered button, or voice-activated command). When the user invokes the user interface mechanism, the device performs the associated <do> element task.

IMPORTANT The <do> element has been extended to support the specification of images as <do> element labels. This is specified with an <img> element embedded inside a <do> element. For example:

If the phone supports images, the localsrc, src and alt are used, in that order. If the phone does not support images, alt specifies the label.

If an <img> element is specified, the label attribute on <do> is ignored. If <img> is not specified, the label attribute on the <do> element is used.

Syntax

<do type="type" label="label" name="name" optional="boolean">

task

</do>

where task represents the action to perform when the user activates the specified interface mechanism:


*`task`*	You must bind one of the following task elements to the user interface mechanism:
		`<go>` `<prev>` `<noop>` `<refresh>`	(see <go> element) (see <prev> element) (see <noop> element) (see <refresh> element)

Attributes

type	Identifies the generic user interface mechanism that triggers the specified `<do>` element task (see descriptions below).
`label`	A label that identifies the task with the user interface mechanism. For example, if you bind a task to the `ACCEPT` key, the device displays this value as the function key label. If you do not specify the `label` attribute, the device uses the word "OK" as the default `ACCEPT` key label. To ensure compatibility on a wide range of devices, *`label`* should be a maximum of five characters. Devices ignore the `label` attribute if they do not support dynamic labelling. The UP.Browser software does not currently support this attribute for the following `TYPE`* values (see above):* *`type="delete"`* *`type="help"`* *`type="prev"`*
`name`	Specifies a name for the `<do>` element. If a card-level `<do>` element (i.e. defined within a `<card>` element) has the same name as a deck-level `<do>` element (i.e. defined within a `<template>` element), the card-level binding overrides the deck-level binding.
`optional`	`true` \| `false` Specifies whether the device can ignore this element.

You can specify the following values for the type attribute (all types are reserved except where noted):

type value	Perform task if user ...
`accept`	Invokes `ACCEPT` mechanism (function key, button, etc.).
`delete`	Invokes `DELETE` mechanism (function key, button, etc.).
`help`	Invokes `HELP` mechanism (may be context-sensitive).
`options`	Invokes `OPTIONS` mechanism (function key, button, etc.).
`prev`	Navigates to card by invoking `PREV` mechanism from another card.
`reset`	Invokes `RESET` mechanism (clears or resets current device state). The UP.Browser does not currently support this attribute value.
`unknown`	Invokes unknown mechanism (equivalent to `TYPE=""`). The UP.Browser does not currently support this attribute value.
`vnd.co-type`	Invokes a vendor-specific mechanism where *`co`* identifies the vendor and *`type`* identifies the action (not reserved). The UP.Browser does not currently support this attribute value.
`X-, x-`	Future use (not reserved). The UP.Browser does not currently support this attribute value.

None of these type values imply a specific user interface mechanism. Some devices map each type to a physical key, while others map them to context-dependent gestures (for example, pressing or press-holding a jog shuttle). Thus, when designing your user interface, keep in mind that you cannot specify (or assume) the particular mechanism that a device will use.

NOTE If you define multiple <do> elements of the same type in one card, you should specify the name attribute for each <do> element to uniquely identify each instance of the same type.